Application program interfaces and structures in a resource limited operating system

ABSTRACT

A set of Application Program Interfaces (APIs) for a resource-limited environment are disclosed. The APIs provide a mechanism for a computer application to interface with various components and modules of an operating system for a resource-limited environment. The APIs further provide a mechanism to interface with input/output devices commonly found in embedded systems running in a resource-limited environment.

CROSS-REFERENCE TO RELATED APPLICATIONS

The present application is a continuation application ofcommonly-assigned U.S. patent application Ser. No. 09/560,546 filed Apr.28, 2000, entitled “Application Program Interfaces and Structures in aResource Limited Operating System”. That patent application is adivisional application of U.S. Pat. No. 6,671,745 entitled “ApplicationProgram Interfaces and Structures in a Resource Limited OperatingSystem” issued Dec. 30, 2003, and claims priority to U.S. provisionalpatent application Ser. No. 60/078,946 also entitled “ApplicationProgram Interfaces and Structures in a Resource Limited OperatingSystem” filed Mar. 23, 1998, and which are incorporated herein byreference.

COPYRIGHT NOTICE/PERMISSION

A portion of the disclosure of this patent document contains materialwhich is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure as it appears in the Patent and TrademarkOffice patent file or records, but otherwise reserves all copyrightrights whatsoever. The following notice applies to the software and dataas described below and in the drawing hereto: Copyright @ 1998, 1999,Microsoft Corporation, All Rights Reserved.

BACKGROUND OF THE INVENTION

1. The Field of the Invention

This invention relates generally to computer operating systems, and moreparticularly to application program interfaces for resource limitedoperating systems.

2. Background and Relevant Art

The rapid evolution of personal computer technology continues to producepersonal computers (PCs) that are smaller, cheaper and faster than theirpredecessors. Where computers once occupied entire rooms, they are nowsmall enough to fit in the palm of a user's hand, hence the name“Palm-size PCs”. In addition, PCs are now small enough to be placed inenvironments outside of the home or office, such as an automobile.Further more, the new PCs may be embedded in a variety of consumerdevices and specialized industrial controllers. For the purposes of thisapplication, all of the above-referenced PCs will be referred tocollectively as “embedded systems.”

The reduced size of embedded systems means that certain sacrifices needto be made. For example, a typical embedded system does not have fixedor removable disk drives such as hard disk, floppy disk, CD-ROM orDVD-ROM drives, with the persistent storage of a typical embedded systemcomprising flash memory or volatile memory with a battery refresh. Inaddition, the amount of RAM in the typical embedded system is alsolimited.

In addition, output resources typical to a desktop PC may be missing orseverely limited in an embedded system. For example, the display for atypical embedded system may comprise a small LCD screen with limitedresolution and capable of displaying only grayscale or a limited numberof colors. In certain environments, such as the automobile, the displaymay be an LCD screen with a limited number of fixed icons and textareas. The display may be augmented with a computerized speech facility.

Similarly, input resources may be limited or adapted for use in embeddedsystems. For example, many embedded systems do not have a mouse or otherpointing device. In addition, some hand-held devices do not have aphysical keyboard. Such embedded devices may use a touch sensitivedisplay in conjunction with a virtual keyboard placed on the display. Inaddition, embedded devices may employ speech recognition for input.

As a result of the above, specialized operating systems capable ofrunning in the resource-limited environment of the embedded system havebeen developed. An example of such an operating system is the WindowsCETM operating system from Microsoft Corporation.

Applications running on the embedded system must also be capable ofrunning in the resource limited environment described above. In embeddedsystems comprising Palm-size PCs, these applications are typicallyspecialized versions of applications available on the bigger siblings ofthe Palm-size PC, such as calendar programs, personal informationmanagers, calculators, dictionaries and the like.

In other environments, the applications running on the embedded systemmay be more specialized. For example, in an AutoPC, the applications maycomprise applications that interface with an audio system, applicationsthat report and use position and navigation information, andapplications that monitor the condition and state of various othersystems present in the automobile.

In order to accommodate a large number of different application needs,operating systems typically provide APIs (Application ProgrammingInterfaces) to a wide variety of functionality that is common to manydiffering applications. Anyone application generally uses only a smallsubset of the available APIs. Providing a wide variety of APIs freesapplication developers from having to write code that would have to bepotentially duplicated in each application. However, in the resourcelimited environment of the embedded system, there is typically a muchmore limited set of APIs available. This is because there is generallyinsufficient persistent and non-persistent memory available to support alarge number of different APIs. Thus, a developer writing an applicationfor an embedded system may find that he or she must develop code thatwould ordinarily be provided by the operating system in a desktop's orother larger computer's operating system.

As a result of the above, there is a need in the art for an operatingsystem capable of running in the resource limited environment of anembedded system. Such an operating system should be customizable andadaptable to the wide variety environments that system designers maychoose to place embedded systems, allowing developers to include onlythose components and modules that are necessary for a particularenvironment. In addition, the operating system should include APIs tooperating system provided components in order prevent applicationsdesigners from having to duplicate commonly needed code. Finally, theoperating system should provide APIs for components and modules thatmeet the unique input and output needs of an embedded system.

BRIEF SUMMARY OF THE INVENTION

The above-mentioned shortcomings, disadvantages and problems areaddressed by the present invention, which will be understood by readingand studying the following specification.

A system is presented that includes a set of Application ProgramInterfaces (APIs) for a number of software modules and components forresource limited environments. One example of a resource limitedenvironment is the embedded system, which comprises a variety ofconsumer devices and specialized industrial controllers, along withhand-held, or palm-size personal computers.

One aspect of the system is that the combination of components andmodules included in an operating system for resource limitedenvironments is customizable and flexible. This allows an embeddedsystem designer -to include only those components and modules that arenecessary for a particular environment. As a result, scarce memory isnot consumed by unneeded components, allowing more memory to be devotedto applications and other modules and components that are needed in theembedded system.

Another aspect of the system is that APIs are provided that meet theunique input and output needs of the typical embedded system. Forexample, many embedded systems do not provided a keyboard or mouse forinput. The system provides APIs to components and modules that providealternative mechanisms of providing input. These alternative mechanismsinclude APIs to handwriting recognition engines that “read” strokes on atouch sensitive screen, and APIs to voice input components that allow auser to issue spoken commands to the system. Further, the systemprovides APIs to components that output audible speech for thoseenvironments where a display monitor is impractical.

Another aspect of the system is that the handling of “out of memory”conditions is customizable by an embedded system designer. This isimportant to systems with limited resources, because out of memoryconditions are more likely to occur.

A further aspect of the system is that an API to a position andnavigation component is provided. This is useful for embedded systemenvironments that are mobile, such as automobiles, trucks, and boats.

The APIs summarized above, and various other APIs, will be described indetail in the next section and in the attached appendices.

The present invention describes systems, clients, servers, methods, andcomputer-readable media of varying scope. In addition to the aspects andadvantages of the present invention described in this summary, furtheraspects and advantages of the invention will become apparent byreference to the drawings and by reading the detailed description thatfollows.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 shows a diagram of the hardware and operating environment inconjunction with which embodiments of the invention may be practiced;

FIG. 2 is a diagram illustrating a system-level overview of exemplaryembodiments of an operating system for a resource limited environment;and

FIG. 3 is a diagram further illustrating the relationship of modules,components and APIs according to an embodiment of the invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In the following detailed description of exemplary embodiments of theinvention, reference is made to the accompanying drawings and theappendices on CD-ROM that form a part hereof, and in which is shown byway of illustration specific exemplary embodiments in which theinvention may be practiced. These embodiments are described insufficient detail to enable those skilled in the art to practice theinvention, and it is to be understood that other embodiments may beutilized and that logical, mechanical, electrical and other changes maybe made without departing from the spirit or scope of the presentinvention. The following detailed description is, therefore, not to betaken in a limiting sense, and the scope of the present invention isdefined only by the appended claims.

The detailed description is divided into four sections. In the firstsection, the hardware and the operating environment in conjunction withwhich embodiments of the invention may be practiced are described. Inthe second section, a system level overview of the invention ispresented. In the third section, various APIs are presented allowingapplications to interface with various modules and components of anoperating system. Finally, in the fourth section, a conclusion of thedetailed description is provided.

Hardware and Operating Environment

FIG. 1 is a diagram of the hardware and operating environment inconjunction with which embodiments of the invention may be practiced.The description of FIG. 1 is intended to provide a brief, generaldescription of suitable computer hardware and a suitable computingenvironment in conjunction with which the invention may be implemented.Although not required, the invention is described in the general contextof computer-executable instructions, such as program modules, beingexecuted by a computer, such as a personal computer, a hand-held orpalm-size computer, or an embedded system such as a computer in aconsumer device or specialized industrial controller. Generally, programmodules include routines, programs, objects, components, datastructures, etc., that perform particular tasks or implement particularabstract data types.

Moreover, those skilled in the art will appreciate that the inventionmay be practiced with other computer system configurations, includinghand-held devices, multiprocessor systems, microprocessor-based orprogrammable consumer electronics, network PCS, minicomputers, mainframecomputers, and the like. The invention may also be practiced indistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network. Ina distributed computing environment, program modules may be located inboth local and remote memory storage devices.

The exemplary hardware and operating environment of FIG. 1 forimplementing the invention includes a general purpose computing devicein the form of a computer 20, including a processing unit 21, a systemmemory 22, and a system bus 23 that operatively couples various systemcomponents including the system memory to the processing unit 21. Theremay be only one or there may be more than one processing unit 21, suchthat the processor of computer 20 comprises a single central-processingunit (CPU), or a plurality of processing units, commonly referred to asa parallel processing environment. The computer 20 may be a conventionalcomputer, a distributed computer, or any other type of computer; theinvention is not so limited.

The system bus 23 may be any of several types of bus structuresincluding a memory bus or memory controller, a peripheral bus, and alocal bus using any of a variety of bus architectures. The system memorymay also be referred to as simply the memory, and includes read onlymemory (ROM) 24 and random access memory (RAM) 25. A basic input/outputsystem (BIOS) 26, containing the basic routines that help to transferinformation between elements within the computer 20, such as duringstart-up, is stored in ROM 24. In one embodiment of the invention, thecomputer 20 further includes a hard disk drive 27 for reading from andwriting to a hard disk, not shown, a magnetic disk drive 28 for readingfrom or writing to a removable magnetic disk 29, and an optical diskdrive 30 for reading from or writing to a removable optical disk 31 suchas a CD ROM or other optical media. In alternative embodiments of theinvention, the functionality provided by the hard disk drive 27,magnetic disk 29 and optical disk drive 30 is emulated using volatile ornon-volatile RAM in order to conserve power and reduce the size of thesystem. In these alternative embodiments, the RAM may be fixed in thecomputer system, or it may be a removable RAM device, such as a CompactFlash memory card.

In an embodiment of the invention, the hard disk drive 27, magnetic diskdrive 28, and optical disk drive 30 are connected to the system bus 23by a hard disk drive interface 32, a magnetic disk drive interface 33,and an optical disk drive interface 34, respectively. The drives andtheir associated computer-readable media provide nonvolatile storage ofcomputer-readable instructions, data structures, program modules andother data for the computer 20. It should be appreciated by thoseskilled in the art that any type of computer-readable media which canstore data that is accessible by a computer, such as magnetic cassettes,flash memory cards, digital video disks, Bernoulli cartridges, randomaccess memories (RAMs), read only memories (ROMs), and the like, may beused in the exemplary operating environment.

A number of program modules may be stored on the hard disk, magneticdisk 29, optical disk 31, ROM 24, or RAM 2S, including an operatingsystem 3S, one or more application programs 36, other program modules37, and program data 38. A user may enter commands and information intothe personal computer 20 through input devices such as a keyboard 40 andpointing device 42. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, touch sensitivepad, or the like. These and other input devices are often connected tothe processing unit 21 through a serial port interface 46 that iscoupled to the system bus, but may be connected by other interfaces,such as a parallel port, game port, or a universal serial bus (USB). Inaddition, input to the system may be provided by a microphone to receiveaudio input.

A monitor 47 or other type of display device is also connected to thesystem bus 23 via an interface, such as a video adapter 48. In oneembodiment of the invention, the monitor comprises a Liquid CrystalDisplay (LCD). In addition to the monitor, computers typically includeother peripheral output devices (not shown), such as speakers andprinters.

The computer 20 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer49. These logical connections are achieved by a communication devicecoupled to or a part of the computer 20; the invention is not limited toa particular type of communications device. The remote computer 49 maybe another computer, a server, a router, a network PC, a client, a peerdevice or other common network node, and typically includes many or allof the elements described above relative to the computer 20, althoughonly a memory storage device 50 has been illustrated in FIG. 1. Thelogical connections depicted in FIG. 1 include a local-area network(LAN) 51 and a wide-area network (WAN) 52. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN-networking environment, the computer 20 is connectedto the local network 51 through a network interface or adapter 53, whichis one type of communications device. When used in a WAN-networkingenvironment, the computer 20 typically includes a modem 54, a type ofcommunications device, or any other type of communications device forestablishing communications over the wide area network 52, such as theInternet. The modem 54, which may be internal or external, is connectedto the system bus 23 via the serial port interface 46. In a networkedenvironment, program modules depicted relative to the personal computer20, or portions thereof, may be stored in the remote memory storagedevice. It is appreciated that the network connections shown areexemplary and other means of and communications devices for establishinga communications link between the computers may be used.

The hardware and operating environment in conjunction with whichembodiments of the invention may be practiced has been described. Thecomputer in conjunction with which embodiments of the invention may bepracticed may be a conventional computer an hand-held or palm-sizecomputer, a computer in an embedded system, a distributed computer, orany other type of computer; the invention is not so limited. Such acomputer typically includes one or more processing units as itsprocessor, and a computer-readable medium such as a memory. The computermay also include a communications device such as a network adapter or amodem, so that it is able to communicatively couple other computers.

System Level Overview

A system level overview of the operation of an exemplary embodiment ofthe invention is described by reference to FIGS. 2 and 3. The conceptsof the invention are described as operating in a multiprocessing,multithreaded operating environment on a computer, such as computer 20in FIG. 1. The exemplary operating environment comprises what is knownin the art as an operating system. In this environment one or moreapplications, such application 226, interface with various modules andcomponents of the operating system. In addition, the various modules andcomponents of the operating system interface with each other. Finally,the modules, components and applications interface with hardware 202present on the computer through what is known in the art as a devicedriver module, and through an Original Equipment Manufacturer (OEM)adaptation layer 208. In one embodiment of the invention, there are twotypes of device drivers, built-in drivers 206 and installable drivers204. The various modules will now be described in further detail.

The core system interface 220 is the module through which applicationscan access the operating system. The core system interface 220 includesfunctions to transfer API calls to the appropriate operating systemserver process. In addition to including or exporting the APIs selected,the core system interface 220 includes components to support thefollowing:

-   -   Localization    -   Local heap and memory allocation    -   Serial port device driver thunks    -   Telephony API (T API)

The shell module 222 manages the user interface and handles such tasksas launching software applications. In one embodiment of the invention,the operating system provides shell components that enable an embeddedsystem designer to develop a customized shell 222 that satisfies therequirements of the target platform. Included in these components are:

-   -   A Control Panel with applets familiar to desktop Windows users.        The following applets are included: Communications; Display;        Keyboard; Network; Owner; Password; Power; Regional Settings,        Remove Programs; Pointing Device Settings (Stylus); Sounds and        Volume.    -   A Notification API that lets an application register its name        and an event with the system. When the event occurs, the kernel        will automatically start the named application. The API also        allows an application to register a specific date and time at        which the application should start.    -   Common controls and common dialogs, which are designed to        provide to the user clear, simple, and meaningful information        and a means to furnish input to the system and applications as        needed.    -   A command line processor (that is, a console application) that        supports a set of standard input and output API calls.    -   Connectivity components (for example, to support remote        application programming calls) between the development        workstation and the embedded system target platform.

In conjunction with a desktop, the shell module 222 also includes adesktop and task manager component that can be optionally included orreplaced. The task manager component includes the following basicfunctionality:

-   -   An Active Tasks list of all the currently running, top-level        applications;    -   A Run button that allows a user to launch a software        application;    -   A Switch To button that allows a user to switch to an        application selected in the Active Tasks listbox.    -   An End Task button that allows a user to terminate an        application selected in the Active Tasks listbox.    -   A Cancel button that allows a user to close the Task-Manager        window.    -   Monitors the level of main battery and backup battery power (for        battery-operated target platforms) and displays an appropriate        warning dialog box.    -   Monitors system memory usage in the system and sends a message        to all top-level windows when the available system memory drops        below a specific threshold. This allows applications to respond        to the message by reducing their memory usage as much as        possible.

The Add-on Technologies module 224 allows an embedded system developerto optionally include components such as OLE/COM automation thatsupports development of ActiveX-based applications, an active desktopshell and an Internet browser. Other components that can be included areVisual Basic run-time and Java script, and a subset of the MicrosoftFoundation Classes (MFC). A further optional component that can beprovided is a handwriting recognition engine with associated APIs. Inone embodiment of the invention, handwriting applications interface witha touch sensitive input device through a component providing a softwareinterface to the touch sensitive device.

The kernel module 214 represents the base operating system functionalitythat must be present on all platforms. The kernel module includes memorymanagement, process management, exception handling, and support formultitasking and multithreading.

In one embodiment of the invention, the kernel 214 is designedspecifically for small, fast, embedded devices. In this embodiment, thekernel supports a single 4GB address space (a 2GB virtual address and a2GB physical address range). In an embodiment of the invention, this 4GBaddress space is divided into 33 “slots”, each of which has a size of32MB. The kernel protects each process by assigning each process to aunique, open slot in memory. The invention, however, is not limited toany particular physical or virtual address space or slot size, and othersizes may be chosen as those of skill in the art will recognize.

The kernel 214 protects applications-from accessing memory outside oftheir allocated slot by generating an exception. Applications can checkfor and handle such exceptions by using the try and except Windows CEfunctions. In one embodiment of the invention, the system is limited to32 processes, but the number of threads running in a process is limitedonly by the amount of available memory. Those of skill in the art willappreciate that other values for the maximum number of processes couldbe chosen.

The file system module 218 contains the functions that supportpersistent storage on the embedded system target platform. This storageis referred to as the “object store” and includes three different waysto store user data:

-   -   The file system. The file system typically supports common file        manipulation functions, such as functions to create files and        directories, read and write to files, and retrieve file and        directory information.    -   The registry. The system registry is similar to the registries        of the Windows 95 and Windows NT operating systems. The registry        for all applications, including the applications bundled in ROM,        is stored in the object store.    -   The Database API. The operating system, in one embodiment of the        invention, has its own structured storage to offer an        alternative to exposing user and application data in files or        the registry. For example, a database is useful for storing raw        data that an application will process before displaying to the        end-user. Hand-held PC applications typically store schedule and        contact information in databases.

In one embodiment of the invention, the file system managed by filesystem module 218 is a transactioned system to reduce the possibilitythat data will be lost due to a critical failure, such as loss of power.Additionally, in one embodiment of the invention, the file system module218 implements a scheme (transactioned) of “mirroring” to mirror ortrack file system operations (not transactioned). The purpose for thisimplementation is to be able to restore a file system volume in the casethat power is lost during a critical sequence of operations beingperformed on the volume.

In one embodiment of the invention, the operating environment combinesthe Win32 User and GDI (Graphics Device Interface) libraries into a GWES(Graphics, Windowing, and Events Subsystem) module 212. The eventmanager and window manager are analogous to Win32 User, and the Win32GDI is replaced with a smaller GDI more suitable to embedded systems.The GWES module 212 includes multiplatform GDI components (supporting anassociated display driver) that support color and grayscale display,palette management, True Type fonts, Raster fonts, cursors, and printerdevice contexts (DCs).

The GWES module 212 also supports a window management component thatprovides API functions tailored for the smaller display sizes typical ofembedded operating systems.

The operating environment of various embodiments of the invention isevent-driven. GWES module includes components to handle events, which inone embodiment of the invention are implemented as messages.

Communications module 216 includes a variety of communications componentoptions to support communications hardware. This includes serial,parallel, and network (wired and wireless) communications.Communications module 216 includes the following selectablecommunications features:

-   -   Serial I/O support    -   Networking support including:        -   NDIS 4.0 for local area networking        -   PPP and SLIP for serial link and modem networking        -   Client-side Remote Access server (RAS)        -   Internet protocols        -   Telephony API (T APO)        -   PC Card support        -   Infrared transceiver support

In one embodiment of the invention, an embedded systems designer mustdevelop the OEM adaptation layer 208 to create the platform specifickernel module 214. The OEM Adaptation Layer (OAL) module 208 allows anembedded system developer to adapt the operating system for a specifictarget platform by creating a thin layer of code that resides betweenthe kernel module 214 and the target platform hardware 202. The OALmodule 208 is specific for a particular CPU and target platform.

The OAL module 208 includes interfaces such as the following:

-   -   Interrupt service routine (ISR) handlers to support device        drivers    -   Real-time clock (RTC)    -   Interval timer (used for the scheduler operation)

In one embodiment of the invention, the RTC and interval timer does notneed to be adapted because it is provided on the CPU. In this case,these interfaces are implemented in the kernel module 214 rather than inthe OAL 208.

In addition to managing such functions as timing and power, the primarypurpose of the OAL is to expose the target platform's hardware 202 tothe kernel module 214. That is, each hardware interrupt request line(IRQ) is associated with one interrupt service routine (ISR). Wheninterrupts are enabled and an interrupt occurs, the kernel calls theregistered ISR for that interrupt.

Built in drivers 206 are device drivers that are linked with GWES module212 when building the operating system. Examples of such drivers are thenotification LED driver or the battery driver. These drivers are called“built-in device drivers” because they ultimately form part of the sameexecutable image as the rest of the operating system. Built-in devicedrivers each have a custom interface to the rest of operating system.

Device Manager module 210 is a module that handles installable devicedrivers. In one embodiment of the invention, The Device Manager 210performs the following tasks:

-   -   Initiates the loading of a driver at system start up, or when it        receives a notification that a third-party peripheral has been        attached to the target platform. For example, when a PC Card is        inserted, Device Manager 210 will attempt to locate and load a        device driver for that PC Card.    -   Registers special filesystem entries with the kernel that map        the Stream I/O Interface functions used by applications to the        implementation of those functions in an installable device        driver.    -   Finds the appropriate device driver by obtaining a Plug and Play        ill or by invoking a detection routine to find a driver that can        handle the device.    -   Loads and tracks drivers by reading and writing registry values.    -   Unloads drivers when their devices are no longer needed. For        example, Device Manager 210 will unload a PC Card device driver        when the card is removed.

In one embodiment of the invention, Installable Device Drivers 204 existas standalone DLLs (Dynamic Link Library) that are managed by the DeviceManager 210. Installable device drivers 204 support some types of nativedevices, any peripheral devices that can be connected to the targetplatform, and any special purpose devices that are added to theplatform. This covers devices such as modems, printers, digital cameras,PC Cards (also known as PCMCIA cards), and others.

In one embodiment of the invention; installable device drivers 204 use acommon interface by which their services are exposed to applications.This interface is the Stream I/O Interface.

A description of the relationships between components, modules and theAPIs they expose to applications is presented with reference to FIG. 3.A module 308 is a major functional block of an operating environmentsuch as operating system 200 of FIG. 2. Module 308 exposes an API 302 toapplications such as application 226 of FIG. 2 that allows theapplication to interface and call methods or functions implemented bythe module 308.

Modules may optionally include one or more components 306. Components306 are groups of functions and data that provide capabilities on asmaller scale than modules 308. Like a module 308, a component 306 alsoexposes an API 304 that other applications, modules, and components mayuse to call methods or functions implemented by the component 306.

As can be seen from the discussion above, the various embodiments of theinvention provide advantages over prior systems. One benefit is that theoperating system is modular. This allows an embedded system designer tocreate an operating environment that is optimized for their uniquehardware development platform and application. The developer can selectvarying combinations of the above-described modules and components forinclusion in the operating environment. For example, a developer canbuild an embedded operating system that contains the kernel and aselected set of communications but does not provide a graphical userinterface. Thus, the invention is not limited to any particularcombination of modules and components.

The various embodiments of the invention also provides a mechanism fordevelopers to conserve the limited memory resources of a typicalembedded system, because only those modules and components having APIsthat are necessary for the operating environment need be included.

APIs in a Resource Limited System

The previous section presented a system level overview of modules andcomponents included in a typical operating system for a system withlimited resources. This section, along with the attached appendices onCD-ROM, present novel APIs and data structures related to the modulesand components described above. The APIs detailed below and in theattached appendices on CD-ROM are described in terms of the C/C++programming language. However, the invention, is not so limited, and theAPIs may be defined and implemented in any programming language, asthose of skill in the art will recognize. Furthermore, the names givento the API functions and parameters are meant to be descriptive of theirfunction, however other names or identifiers could be associated withthe functions and parameters, as will be apparent to those of skill inthe art. Six sets of APIs and data structures will be presented:Handwriting Recognition APIs, Position and Navigation APIs, Speechrelated APIs, Out of Memory APIs, Database APIs and Active Synch DataStructures.

1. Handwriting Recognition APIs

A handwriting recognition component is available in the Add-OnTechnologies module 224 (FIG. 2). The handwriting recognition componentimplements a handwriting recognition engine. In one embodiment of theinvention, the engine receives “ink” in the form of a plurality ofstrokes on a touch sensitive screen. The strokes are then sent fromapplications to the engine using a variety of APIs. The engine thenattempts to interpret the strokes as alphanumeric characters. Theinterpreted characters are returned to the application via an API. Inone embodiment of the invention, the characters are interpreted asEnglish language characters. In alternative embodiments of theinvention, the characters are interpreted in other languages.

The handwriting recognition component is particularly useful in embeddedsystems that have a touch sensitive display, but no keyboard.Applications that require alphanumeric input can use the charactersreceived from the engine as if they had been typed at a keyboard.

Further details on the APIs used by applications that interface with ahandwriting recognition engine are presented in Appendix G on CD-ROM.

2. Position and Navigation APIs and Data Structures

A Position and Navigation component is available in the Add-OnTechnologies module. The Position and Navigation component allows anapplication to interface with a positioning device (also referred to asa positioning and navigation device) such as an Apollo GPS system. Suchan interface is useful when the embedded system is located in a mobilearticle such as an automobile or truck. In one embodiment of theinvention, the embedded system is the AutoPC.

Further details on the APIs for the Position and Navigation module arefound in Appendix E on CD-ROM. Also, further details on data structuresused by the Position and Navigation Module and related APIs are found inAppendix F on CD-ROM.

3. Speech Related APIs

The Add-On Technologies module contains several speech-relatedcomponents that expose APIs for application use. These componentsinclude a text-to-speech component, a voice-to-text component, and avoice command component. In general, these components are intended forenvironments where input and output devices are limited, and where auser's interaction with the embedded system is via speech. An example ofsuch an environment is the AutoPC. Because the driver must use theirhands in the operation of the automobile, interaction with the AutoPC isvia a speech interface, where input commands are spoken by the user, andoutput from the PC is converted from text to speech.

Further details on the text-to-speech APIs are presented in the AppendixH on CD-ROM. Further details on the voice command and speech to textAPIs are presented in Appendices I, J and K on CD-ROM.

4. Out of Memory API

The Out of Memory API is a component of the OWES module. This componentallows an embedded system developer to replace the default action thatoccurs when the operating system detects that the system is running outof available memory in which to run applications or place data.

The Out of Memory component is significant to an operating systemintended for limited resource environments, because the condition ismore likely to occur in an embedded system than in a desk-top system.The API exposed provides a standardized way for the operating system tocall customized software that meets the specific needs of an embeddedsystem developer.

Further details on the out of memory API are presented in Appendix L onCD-ROM.

5. Database API

As discussed above in reference to FIG. 2, the file system module 218may optionally include a database component. The database componentallows applications to create and maintain databases as file systemobjects. Applications make calls to various API functions that maintainthe database. These functions include functions that create newdatabases, open existing database, delete databases, seeks particularrecords in databases, read records from databases and write records todatabases. In addition, the Database API includes functions thatnavigate through a list of databases of a given type. Further detailsregarding the Database API are presented in Appendix C on CD-ROM.

6. ActiveSync Data Structures

ActiveSync is a component available in the Add-On Technologies module.The ActiveSync component provides a service that allows applications tocompare two objects to determine if one of the objects needs to beupdated in order for the objects to be “synchronized”, that is, thesame. Typically the objects are file system objects containingapplication data. ActiveSync is particularly useful when applied tohand-held PCs. This is because the user often will update datamaintained in a file system object on the hand-held PC, and then need toupdate a file on a desk-top PC so that the two files contain the samedata. For example, hand-held PCs typically provide an application suchas a Personal Information Manager that maintains a database ofinformation, including telephone numbers. If a user maintains a similardatabase of telephone numbers on both their hand-held PC and theirdesk-top PC, it is desirable that the two telephone directories reflectupdates made to either the hand-held PC or desk-top PC database.ActiveSync allows a user to accomplish this.

In one embodiment of the invention, several data structures are employedthat enable ActiveSync to correctly compare and perform updates tocorresponding objects. The first data structure is the CONFINFO datastructure. This data structure is used to retrieve information about twopotentially conflicting items. In one embodiment of the invention, anActiveSync Server presents the information in the CONFINFO datastructure to a user via a dialogue box to allow the user to choose anoption for resolving the conflict. Further details regarding theCONFINFO data structure are presented in Appendix A on CD-ROM.

A second data structure used by the. Active Synch component is theOBJNOTIFY structure. The OBJNOTIFY data structure is used to notify theActiveSync service provider that an object in the file system haschanged or been deleted. Further details regarding the OBJNOTIFY datastructure are presented in Appendix A on CD-ROM.

Conclusion

APIs for modules and components of a resource-limited operating systemhave been described. The APIs provide access to specialized hardware andsoftware that is desirable in such limited-resource systems.

Although specific embodiments have been illustrated and describedherein, it will be appreciated by those of ordinary skill in the artthat any arrangement which is calculated to achieve the same purpose maybe substituted for the specific embodiments shown. This application isintended to cover any adaptations or variations of the presentinvention.

For example, those of ordinary skill within the art will appreciate thatwhile the embodiments of the invention have been described as beingimplemented in a resource-limited environment, the principles of theinvention are applicable to other environments. For example, the voicecommand APIs can be adapted to standard desk-top operating system to aiduser's who have difficulty using a conventional keyboard and mouse toprovide input to a system.

Furthermore, while some examples in the detailed description above arediscussed in terms of the Windows CE operating system, the systems,methods and APIs of the invention may be applied to any operatingsystem.

The terminology used in this application is meant to include all ofthese environments. Therefore, it is manifestly intended that thisinvention be limited only by the following claims and equivalentsthereof.

1. A set of application program interfaces embodied on acomputer-readable medium for execution on a computer in conjunction withan application that manages at least one voice command menu, comprising:a first interface that receives a handle of a window associated with theat least one voice command menu and a flag indicating when the menushould be active in relation to a speech recognition status; a secondinterface that receives a list of command structures, each of saidcommand structures describing a voice command, and that returns a numberassociated with a first voice command added to the at least one voicecommand menu; a third interface that deactivates the at least one voicecommand menu; and a fourth interface that receives a numbercorresponding to a first voice command, a number of voice commands toremove and that removes the number of voice commands from the at leastone voice command menu, said removal starting with the numbercorresponding to the first voice command.
 2. A set of applicationprogram interfaces embodied on a computer-readable medium for executionon a computer in conjunction with an application that manages a voicecommand menu, comprising: a first interface that receives an enablementparameter from an application, said enablement parameter operative tocause a voice recognition component to enable voice recognition when theenablement parameter has a first value and to disable voice recognitionwhen the enablement parameter has a second value; and a second interfacethat returns a second parameter to the application, said secondparameter operative to indicate that voice recognition is enabled whenthe second parameter has the first value and that voice recognition isdisabled when the second parameter has the second value.
 3. A set ofapplication program interfaces embodied on a computer-readable mediumfor execution on a computer in conjunction with an application thatmanages a voice command menu, comprising: a first interface thatreceives a first voice command structure identifying a voice menu and acommand string, said voice command structure having an association witha second application; a second interface that receives an identifier ofa recognized voice command, a second voice command structure identifyinga voice menu associated with the recognized voice command, averification required flag, an action data string, a list containing atleast one recognized phrase of the recognized voice command, and acommand string corresponding the recognized command; a third interfacethat is called when a spoken phrase is detected by a voice commandcomponent; and a fourth interface that receives a type of interferencedetected by the voice command component.
 4. A set of application programinterfaces embodied on a computer-readable medium for execution on acomputer in conjunction with an application that manages a voice commandmenu, comprising: a first interface that receives a menu identifierstructure, said menu identifier structure comprising an application nameand a state name, a language identifier structure and a mode flag froman application that causes a voice recognition system to create a voicecommand menu identified by the menu identifier structure; and a secondinterface that receives the menu identifier structure from anapplication and that causes the voice recognition system to delete thevoice command menu identified by the menu identifier structure.
 5. Acomputer system comprising: a computer comprising a processor and amemory operatively coupled together; an operating system executing inthe processor, said operating system having a voice recognitioncomponent; and an application program running under the control of theoperating system; application program interfaces associated with thevoice recognition component, said application program interfacesoperative to receive data from the application and send data to theapplication, the application program interfaces comprising: an interfacethat receives a handle of a window associated with the at least onevoice command menu and a flag indicating when the menu should be activein relation to a speech recognition status; an interface that receives alist of command structures, each of said command structures describing avoice command, and that returns a number associated with a first voicecommand added to the at least one voice command menu; an interface thatdeactivates the at least one voice command menu; and an interface thatreceives a number corresponding to a first voice command, a number ofvoice commands to remove and that removes the number of voice commandsfrom the at least one voice command menu, said removal starting with thenumber corresponding to the first voice command.
 6. The computer systemof claim 5, wherein the application program interfaces further comprise:an interface that receives an enablement parameter from the application,said enablement parameter operative to cause the voice recognitioncomponent to enable voice recognition when the enablement parameter hasa first value and to disable voice recognition when the enablementparameter has a second value; and an interface that returns a secondparameter to the application, said second parameter operative toindicate that voice recognition is enabled when the second parameter hasthe first value and that voice recognition is disabled when the secondparameter has the second value.
 7. The computer system of claim 5,wherein the application program interfaces further comprise: aninterface that receives from the application a first voice commandstructure identifying a voice menu and a command string, said voicecommand structure having an association with a second application; aninterface that receives an identifier of a recognized voice command, asecond voice command structure identifying a voice menu associated withthe recognized voice command, a verification required flag, an actiondata string, a list containing at least one recognized phrase of therecognized voice command, and a command string corresponding therecognized command; an interface that is called when a spoken phrase isdetected by the voice recognition component; and an interface thatreceives a type of interference detected by the voice recognitioncomponent.
 8. The computer system of claim 5, wherein the applicationprogram interfaces further comprise: an interface that receives a menuidentifier structure, said menu identifier structure comprising anapplication name and a state name, a language identifier structure and amode flag from an application that causes a voice recognition system tocreate a voice command menu identified by the menu identifier structure;and an interface that receives the menu identifier structure from anapplication and that causes the voice recognition system to delete thevoice command menu identified by the menu identifier structure.
 9. In acomputing system that includes an application for responding to voicecommands in a limited resource environment, a method for allowing theapplication to interface with voice recognition components, the methodcomprising: an act of receiving a handle of a window associated with theat least one voice command menu and a flag indicating when the menushould be active in relation to a speech recognition status; an act ofreceiving a list of command structures, each of said command structuresdescribing a voice command, and thereafter returning a number associatedwith a first voice command added to the at least one voice command menu;an act of deactivating the at least one voice command menu; and an actof receiving a number corresponding to a first voice command and anumber of voice commands to remove and thereafter removing the number ofvoice commands from the at least one voice command menu, said removalstarting with the number corresponding to the first voice command.
 10. Amethod as recited in claim 9, the method further comprising: an act ofreceiving an enablement parameter from the application, said enablementparameter operative to cause the voice recognition component to enablevoice recognition when the enablement parameter has a first value and todisable voice recognition when the enablement parameter has a secondvalue; and an act of returning a second parameter to the application,said second parameter operative to indicate that voice recognition isenabled when the second parameter has the first value and that voicerecognition is disabled when the second parameter has the second value.11. A method as recited in claim 9, the method further comprising: anact of receiving from the application a first voice command structureidentifying a voice menu and a command string, said voice commandstructure having an association with a second application; an act ofreceiving an identifier of a recognized voice command, a second voicecommand structure identifying a voice menu associated with therecognized voice command, a verification required flag, an action datastring, a list containing at least one recognized phrase of therecognized voice command, and a command string corresponding therecognized command; calling an interface when a spoken phrase isdetected by the voice recognition component; and an act of receiving atype of interference detected by the voice recognition component.
 12. Amethod as recited in claim 9, the method further comprising: an act ofreceiving a menu identifier structure, said menu identifier structurecomprising an application name and a state name, a language identifierstructure and a mode flag from an application that causes a voicerecognition system to create a voice command menu identified by the menuidentifier structure; and an act of receiving the menu identifierstructure from an application and that causes the voice recognitionsystem to delete the voice command menu identified by the menuidentifier structure.
 13. A computer program product for use in acomputing system that includes an application for responding to voicecommands in a limited resource environment and for implementing a methodfor allowing the application to interface with voice recognitioncomponents, the computer program product comprising one or morecomputer-readable media having computer-executable instructions forimplementing the method, the method comprising: an act of receiving ahandle of a window associated with the at least one voice command menuand a flag indicating when the menu should be active in relation to aspeech recognition status; an act of receiving a list of commandstructures, each of said command structures describing a voice command,and thereafter returning a number associated with a first voice commandadded to the at least one voice command menu; an act of deactivating theat least one voice command menu; and an act of receiving a numbercorresponding to a first voice command and a number of voice commands toremove and thereafter removing the number of voice commands from the atleast one voice command menu, said removal starting with the numbercorresponding to the first voice command.
 14. A computer program productas recited in claim 13, wherein the method further comprises: an act ofreceiving an enablement parameter from the application, said enablementparameter operative to cause the voice recognition component to enablevoice recognition when the enablement parameter has a first value and todisable voice recognition when the enablement parameter has a secondvalue; and an act of returning a second parameter to the application,said second parameter operative to indicate that voice recognition isenabled when the second parameter has the first value and that voicerecognition is disabled when the second parameter has the second value.15. A computer program product as recited in claim 13, wherein themethod further comprises: an act of receiving from the application afirst voice command structure identifying a voice menu and a commandstring, said voice command structure having an association with a secondapplication; an act of receiving an identifier of a recognized voicecommand, a second voice command structure identifying a voice menuassociated with the recognized voice command, a verification requiredflag, an action data string, a list containing at least one recognizedphrase of the recognized voice command, and a command stringcorresponding the recognized command; calling an interface when a spokenphrase is detected by the voice recognition component; and an act ofreceiving a type of interference detected by the voice recognitioncomponent.
 16. A computer program product as recited in claim 13,wherein the method further comprises: an act of receiving a menuidentifier structure, said menu identifier structure comprising anapplication name and a state name, a language identifier structure and amode flag from an application that causes a voice recognition system tocreate a voice command menu identified by the menu identifier structure;and an act of receiving the menu identifier structure from anapplication and that causes the voice recognition system to delete thevoice command menu identified by the menu identifier structure.